In a database management system, SQL statements are used to manipulate data and to retrieve data that matches certain selection criteria. A SQL statement is compiled in memory before being executed by a database engine. Though the compiled form of the SQL statement may be cached in memory for some amount of time for repeated executions, it is eventually discarded. Therefore SQL statements can be considered transient objects in a database system.
In practice, the set of SQL statements used by an application are repeatedly executed, and it is highly likely that the same SQL statements appear (are compiled into memory) with certain frequencies. The knowledge that certain SQL statements (especially those critical to application performance) reappear can be taken advantage of by placing special manual controls affecting the performance of the SQL statements.
However, selecting the proper control to insert is difficult or impossible, because execution data for the SQL statement is not collected and is therefore not used as feedback to select a control to influence future executions of a SQL statement. Even if an appropriate control is selected for targeting a SQL statement, the data (or metadata) cannot be associated with the SQL statement, because the SQL statement has no persistent representation. Thus, conventional methods place a control on a SQL statement by either modifying the text of the SQL statement, or by making modifications to the session context in which a SQL statement is executed. Both of these approaches require application changes, which can be difficult and sometimes impossible. Therefore, conventional methods of associating metadata with a SQL statement locate the metadata within the context of the executing SQL statement. If the metadata cannot be located in the execution context of SQL statement, the database system has no other way to deliver the metadata to the database engine when the SQL statement re-appears and is compiled into memory.